home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-iplpdn-para-negotiation-00.txt < prev    next >
Text File  |  1993-03-03  |  14KB  |  434 lines
  1.  
  2.  
  3. Draft               Parameter Negotiation          Feb. 1992
  4.  
  5.  
  6. INTERNET DRAFT
  7. Expires: August 16, 1993
  8.  
  9.  
  10.  
  11.  
  12.            Parameter Negotiation
  13.               for the
  14.          Multiprotocol Interconnect
  15.  
  16.  
  17. Keith Sklower
  18. Computer Science Department
  19. University of California, Berkeley
  20.  
  21. Clifford Frost
  22. Information Systems & Technology
  23. University of California, Berkeley
  24.  
  25. 1.   Status  of  This  Memo    This  document is an Internet
  26. Draft.  Internet Drafts are working documents of the  Inter-
  27. net  Engineering Task Force (IETF), its Areas, and its Work-
  28. ing Groups.  Note that  other  groups  may  also  distribute
  29. working documents as Internet Drafts.
  30.  
  31. Internet  Drafts  are draft documents valid for a maximum of
  32. six months.  Internet Drafts may be  updated,  replaced,  or
  33. obsoleted  by other documents at any time.  It is not appro-
  34. priate to use Internet Drafts as reference  material  or  to
  35. cite  them  other  than  as a ``working draft'' or ``work in
  36. progress.''
  37.  
  38. Please check the 1id-abstracts.txt listing contained in  the
  39. internet-drafts    Shadow    Directories   on   nic.ddn.mil,
  40. nnsc.nsf.net,    nic.nordu.net,     ftp.nisc.sri.com,     or
  41. munnari.oz.au  to  learn  the current status of any Internet
  42. Draft.
  43.  
  44. 2.  Abstract
  45.  
  46. This document describes mechanisms  for  negotiating  opera-
  47. tional  parameters  wherever  SNAP encapsulation of Internet
  48. Protocols is available.  For example, it is suitable for use
  49. in  conjunction  with  RFC  1294  (Multiprotocol  Over Frame
  50. Relay) and RFC 1356 (Multiprotocol Interconnect on X.25  and
  51. ISDN in the Packet Mode) [1,2], and potentially others.  The
  52. mechanisms described here are intended  as  optional  exten-
  53. sions,  intended to facilitate interoperation in public net-
  54. works were preconfiguration may not have been done symmetri-
  55. cally by all parties who wish to exchange information.
  56.  
  57.  
  58. Sklower & Frost                                 [Page 1]
  59.  
  60.  
  61.  
  62. Draft               Parameter Negotiation          Feb. 1992
  63.  
  64.  
  65. 3.  Acknowledgements
  66.  
  67. The  authors wish to thank Brian Lloyd of Lloyd & Associates
  68. for extensive discussion of the PPP protocol,  Brad  Steinke
  69. of  Microcom, and Joel Halpern of Network Systems for useful
  70. suggestions,  and  especially  Chris  Ranch  of  Novell  for
  71. details about the protocol itself.
  72.  
  73. 4.  Conventions
  74.  
  75. The  following language conventions are used in the items of
  76. specification in this document:
  77.  
  78. o    Must, Shall or Mandatory -- the  item  is  an  absolute
  79.      requirement of the specification.
  80.  
  81. o    Should  or  Recommended -- the item should generally be
  82.      followed for all but exceptional circumstances.
  83.  
  84. o    May or Optional -- the item is truly optional  and  may
  85.      be  followed  or  ignored according to the needs of the
  86.      implementor.
  87.  
  88. 5.  Introduction
  89.  
  90. When parties wish to exchange information over a public data
  91. network,  it may be useful to perform sanity checks, such as
  92. verifying that buffer sizes are sufficient to  receive  data
  93. being  transmitted,  or  that there is agreement as to which
  94. protocols will be routed or bridged.   As  another  example,
  95. there may be circumstance in which the identity of a calling
  96. party may not  be  readily  available;  thus  some  form  of
  97. authentication may be desired.
  98.  
  99. The  Point-to-Point  Protocol (RFC 1331 and 1332) provides a
  100. means of achieving these goals [3,4].  It  is  very  general
  101. and can be adapted to any situation where there is a virtual
  102. point-to-point  connection  between   parties   wishing   to
  103. exchange  information.  Since both RFC's 1294 and 1331 spec-
  104. ify details of framing  and  encapsulation  in  incompatible
  105. ways,  there  is a minor modification to PPP's encapsulation
  106. which is required for this context.
  107.  
  108. There are some additional changes that have been proposed to
  109. the  PPP-extensions  working  group for use in this context.
  110. Principally, we would like parameter negotiation as a  whole
  111. to be made optional.  We would also like to be able to rene-
  112. gotiate parameters at any time during the course of an asso-
  113. ciation.   There  was  also expressed the desire to decrease
  114. the number of actual packets  exchanged  to  traverse  PPP's
  115. state  diagram.   A  method  for  doing this was proposed by
  116. emiting compound frames which would be made up  of  multiple
  117. logical  PPP packets.  It was thought that this might reduce
  118.  
  119.  
  120. Sklower & Frost                                 [Page 2]
  121.  
  122.  
  123.  
  124. Draft               Parameter Negotiation          Feb. 1992
  125.  
  126.  
  127. the negotation to an exchange  of  three  actual  link-level
  128. packets.
  129.  
  130. 6.  Frame Format
  131.  
  132. 6.1.  Basic Format
  133.  
  134. In  this  document,  we  propose prepending a SNAP header to
  135. otherwise unchanged PPP (data and control) packets [5].  The
  136. SNAP  header MUST specify an OUI of 0 (Xerox Ethernet Encap-
  137. sulation).  The protocol ID field MUST be (0xZZZZ  -  to  be
  138. obtained).   A  system  SHOULD  recognize  incoming PPP data
  139. packets; however, we RECOMMEND that only control or negotia-
  140. tion  type PPP packets be transmitted in this fashion, since
  141. RFCs 1294 and 1356 already specify a means of  encapsulating
  142. data packets.
  143.  
  144. Since  we  are proposing using this in conjunction with both
  145. RFC1294 and RFC1356, we give an example in each packet  for-
  146. mat:
  147.  
  148.  
  149.      Sample Frame Relay PPP LCP packet
  150.      +-----------------------------+
  151.      |    flag (7E hexadecimal)    |
  152.      +-----------------------------+
  153.      |       Q.922 Address         |
  154.      +--                         --+
  155.      |                             |
  156.      +-----------------------------+
  157.      | Control (UI = 0x03)         |
  158.      +-----------------------------+
  159.      | Optional Pad(s)   (0x00)    |
  160.      +-----------------------------+
  161.      | NLPID              0x80     |
  162.      +-----------------------------+
  163.      | OUI                0x00     |
  164.      +--           .             --+
  165.      | OUI                0x00     |
  166.      +--           .             --+
  167.      | OUI                0x00     |
  168.      |     (three octets)          |
  169.      +-----------------------------+
  170.      | ETHERTYPE       (to be ..   |
  171.      +--           .             --+
  172.      | ETHERTYPE        obtained)  |
  173.      |       (two octets)          |
  174.      +-----------------------------+
  175.      | PPP  Protocol (e.g. 0x0c)   |
  176.      +--           .             --+
  177.      | PPP  Protocol (0x21 for LCP)|
  178.      |       (two octets)          |
  179.      +-----------------------------+
  180.  
  181.  
  182. Sklower & Frost                                 [Page 3]
  183.  
  184.  
  185.  
  186. Draft               Parameter Negotiation          Feb. 1992
  187.  
  188.  
  189.      |           Data              |
  190.      |   (e.g   LCP  Code  )       |
  191.      +-----------------------------+
  192.      |   (e.g   LCP  Identifier)   |
  193.      +-----------------------------+
  194.      |   (e.g.  LCP  Option Length)|
  195.      +--           .             --+
  196.      |       (two octets)          |
  197.      +-----------------------------+
  198.      |   (e.g.  LCP  Option)       |
  199.      |             .               |
  200.      |             .               |
  201.      |             .               |
  202.      |             .               |
  203.      +-----------------------------+
  204.      |   Frame Check Sequence      |
  205.      +--           .             --+
  206.      |       (two octets)          |
  207.      +-----------------------------+
  208.      |   flag (7E hexadecimal)     |
  209.      +-----------------------------+
  210.  
  211.  
  212.     Sample X.25 PPP LCP packet
  213.      +-----------------------------+
  214.      |    flag (7E hexadecimal)    |
  215.      +-----------------------------+
  216.      | Address A or B   0x1 or 0x3 |
  217.      +--                         --+
  218.      |       LAPB Control          |
  219.      +-----------------------------+
  220.      |  D,Q bits | SVC# high order |
  221.      +-----------------------------+
  222.      |       SVC low order         |
  223.      +-----------------------------+
  224.      | p(r)   | m_bit | p(s)   | 0 |
  225.      +-----------------------------+
  226.      | NLPID              0x80     |
  227.      +-----------------------------+
  228.      | OUI                0x00     |
  229.      +--           .             --+
  230.      | OUI                0x00     |
  231.      +--           .             --+
  232.      | OUI                0x00     |
  233.      |     (three octets)          |
  234.      +-----------------------------+
  235.      | ETHERTYPE       (to be ..   |
  236.      +--           .             --+
  237.      | ETHERTYPE        obtained)  |
  238.      |       (two octets)          |
  239.      +-----------------------------+
  240.      | PPP  Protocol (e.g. 0x0c)   |
  241.      +--           .             --+
  242.  
  243.  
  244. Sklower & Frost                                 [Page 4]
  245.  
  246.  
  247.  
  248. Draft               Parameter Negotiation          Feb. 1992
  249.  
  250.  
  251.      | PPP  Protocol (0x21 for LCP)|
  252.      |       (two octets)          |
  253.      +-----------------------------+
  254.      |           Data              |
  255.      |   (e.g   LCP  Code  )       |
  256.      +-----------------------------+
  257.      |   (e.g   LCP  Identifier)   |
  258.      +-----------------------------+
  259.      |   (e.g.  LCP  Option Length)|
  260.      +--           .             --+
  261.      |       (two octets)          |
  262.      +-----------------------------+
  263.      |   (e.g.  LCP  Option)       |
  264.      |             .               |
  265.      |             .               |
  266.      |             .               |
  267.      |             .               |
  268.      +-----------------------------+
  269.      |   Frame Check Sequence      |
  270.      +--           .             --+
  271.      |       (two octets)          |
  272.      +-----------------------------+
  273.      |   flag (7E hexadecimal)     |
  274.      +-----------------------------+
  275.  
  276. 6.2.  Supported Types
  277.  
  278. The  PPP protocol is a rich language and allows many options
  279. to be negotiated.  An implementation MAY request any  option
  280. specified  by  PPP,  but  MAY decline to support any option.
  281. Because PPP and Frame Relay encapsulations evolved  indepen-
  282. dently,  there  are  duplicate  ways to obtain configuration
  283. information such as the IP address of the other end  of  the
  284. PVC  - by inverse arp, or determine the transmit and receive
  285. buffer sizes - by XID negotiation.   Where  there  are  such
  286. choices,  it is RECOMMENDED that an implementation adhere to
  287. practice specified in the Frame Relay and X.25 RFCs.  Manual
  288. configuration  also implicitly provides information that may
  289. otherwise have been explicitly negotiated.
  290.  
  291. 7.  Changes to PPP semantics
  292.  
  293. 7.1.  Optionality and Separability of Negotiations
  294.  
  295. As noted above, people have expressed the desire not  to  be
  296. required  to  conduct  any  negotiations before transmitting
  297. data packets in a public data network environment.  Thus, an
  298. implementation MAY silently ignore any SNAP encapsulated PPP
  299. packet.  If an implementation responds to  LCP  packets,  it
  300. MUST traverse the LCP state diagram according to RFC1331.
  301.  
  302. If an implementation responds to NCP packets for any partic-
  303. ular protocol, it MUST otherwise obey the rules of  the  RFC
  304.  
  305.  
  306. Sklower & Frost                                 [Page 5]
  307.  
  308.  
  309.  
  310. Draft               Parameter Negotiation          Feb. 1992
  311.  
  312.  
  313. for that corresponding NCP.
  314.  
  315. One  reason  for making negotiations optional is cost; there
  316. are environments which charge by the packet  and  there  are
  317. applications such as mail hubs which generally exchange only
  318. a few data packets with a given remote host  and  then  will
  319. not  exchange  any other packets for relatively long periods
  320. of time.
  321.  
  322. Another reason is simplicity of implementation.  For use  of
  323. small  computers at home, people may wish to be able to only
  324. support the required packet framing.   Or,  for  routers  at
  325. campus  or  business hubs, this could reduce memory require-
  326. ments from having to maintain state information for hundreds
  327. of virtual point-to-point connections.
  328.  
  329. Another reason is reduction of latency.
  330.  
  331. 8.  Other Extensions to PPP
  332.  
  333. 8.1.  Protocol Summaries in NCP
  334.  
  335. It  has been suggested that there should be a PPP LCP option
  336. to pre-emptively announce which protocols will be routed  or
  337. bridged,  in lieu of conducting independent negotiations for
  338. each protocol via their separate  NCPs,  The  rationale  for
  339. having  this  option is that it gives what may be for simple
  340. situations the single most important benefit  of  having  an
  341. NCP  at  all (i.e. a sanity check that data packets will not
  342. be black holed) without having  the  complexity  or  latency
  343. requirements of a full blown NCP.
  344.  
  345. 8.2.  Compound PPP packets
  346.  
  347. If  it is desired to conduct several independent NCPs at the
  348. same time, and since there are per-packet charges, it may be
  349. useful  to  bundle  up  several logical PPP packets into the
  350. same physical packet and thus reduce  packet  charges.   The
  351. PPP-extensions  working  group  has  agreed  to advance this
  352. change, and it will be described in a forthcoming  document.
  353.  
  354. 9.  References
  355.  
  356. [1]  Bradley,  T.,  Brown, C., and Malis, A., "Multiprotocol
  357.      Interconnect over Frame Relay", Network Working  Group,
  358.      RFC-1294, January 1992.
  359.  
  360. [2]  Malis,  A.,  Robinson,  D.,  Ullman  R., "Multiprotocol
  361.      Interconnect on X.25 and ISDN in the Packet Mode", Net-
  362.      work Working Group, RFC-1356, August 1992.
  363.  
  364. [3]  Simpson, W., "The Point-to-Point Protocol (PPP) for the
  365.      Transmission of Multi-protocol Datagrams over Point-to-
  366.  
  367.  
  368. Sklower & Frost                                 [Page 6]
  369.  
  370.  
  371.  
  372. Draft               Parameter Negotiation          Feb. 1992
  373.  
  374.  
  375.      Point  Links",  Network  Working  Group,  RFC-1331, May
  376.      1992.
  377.  
  378. [4]  McGregor, G., "The PPP Internet Protocol Control Proto-
  379.      col  (IPCP)" Network Working Group, RFC-1332, May 1992.
  380.  
  381. [5]  Postel, J. and Reynolds, J., "A Standard for the Trans-
  382.      mission  of  IP Datagrams over IEEE 802 Networks", ISI,
  383.      RFC-1042, February 1988.
  384.  
  385. 10.  Authors' Addresses
  386.  
  387. Keith Sklower
  388. Computer Science Department
  389. 570 Evans Hall
  390. University of California
  391. Berkeley, CA  94720
  392.  
  393. Phone:  (510) 642-9587
  394. Email:  sklower@cs.Berkeley.EDU
  395.  
  396.  
  397.  
  398. Clifford Frost
  399. Information Systems & Technology
  400. 275 Evans Hall
  401. University of California
  402. Berkeley, CA  94720
  403.  
  404. Phone:  (510) 642-5360
  405. Email:  cliff@cmsa.Berkeley.EDU
  406.  
  407. 11.  Expiration Date of this Draft
  408.  
  409. August 16, 1993
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430. Sklower & Frost                                 [Page 7]
  431.  
  432.  
  433.  
  434.